Policy and Charging Control (PCC) architecture is specified in 3GPP TS 23.203 (v12.4.0), which discloses the PCC functionality for Evolved 3GPP Packet Switched domain, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. Amongst other entities, the PCC architecture illustrated in FIG. 2 comprises a Policy and Charging Rules Function (PCRF) encompassing policy control decision and flow based charging control functionalities, a Policy and Charging Enforcement Function (PCEF) encompassing service data flow detection (based on filters definitions received in PCC rules) as well as online and offline charging interactions and policy enforcement, an Application Function (AF) offering applications, in which service is delivered in a different layer from the one the service has been requested, the control of IP bearer resources according to what has been negotiated, and an Online Charging System (OCS) to allow charging decisions.
The PCRF provides network control regarding the service data flow detection, gating, quality of service (QoS) and flow based charging (except credit management) towards the PCEF. Since the PCEF is the entity handling bearers, this is where the QoS is being enforced for the bearers according to the QoS information received from the PCRF. The PCRF receives session and media related information from the AF and informs AF of traffic plane events. The AF shall communicate with the PCRF to transfer dynamic session information (i.e. description of the media to be delivered in the transport layer). This communication is performed using the Rx interface.
One example of an AF is a Proxy Call Session Control Function (P-CSCF) of an IP Multimedia Subsystem (IMS) core network. In conventional IMS procedures, the P-CSCF requests the establishment of a new Rx session with the PCRF after having completed a Registration procedure for a UE and intended to subscribe to the status of the IMS signalling path. The PCRF confirms the subscription to IMS signalling path status back to the P-CSCF.
In particular, the PCEF may be located at e.g. a gateway GPRS support node (GGSN) in a general packet radio service (GPRS) core network. The GPRS core network allows 2G, 3G and WCDMA mobile networks to transmit IP packets to external networks such as the Internet. For the cases where there is a Proxy Mobile IP (PMIP) protocol instead of a GPRS tunnelling protocol (GTP) between a Bearer Binding and Event Reporting Function (BBERF) and the PCEF, the bearer control is done in the BBERF instead. Moreover, the PCEF may also be located at e.g. a packet data network gateway (PGW) in an evolved packet system (EPS) network. The PGW, which may also be abbreviated as PDN GW, is the point of interconnect between the evolved packet core (EPC) and the external IP networks. Furthermore, the PCEF may also be located at e.g. a packet data gateway (PDG) for connecting an untrusted WLAN network with a 3GPP network. In this scenario, the PDG may be a gateway to a specific packet data network, such as the internet or an operator service network.
Apart from the conventional PCC entities discussed above, other network nodes can be connected to the PCC architecture. For example, a Mobility Management Entity (MME) responsible for tracking and paging procedures in an EPS network with E-UTRAN access, or a Serving GPRS Support Node supporting the S4 interface (S4-SGSN) for GERAN/UTRAN accesses to an EPS network. The MME is also involved in bearer activation and deactivation procedures, Serving Gateway (SGW) selection, user authentication towards the Home Subscriber Server (HSS), authorization and enforcement of User Equipment (UE) roaming restrictions and mobility between LTE and 2G/3G; and the S4-SGSN is responsible for adapting the GPRS procedures into EPS procedures, and supports a similar functionality as the MME. More specifically, the term “54-SGSN” refers to a Release-8 SGSN that has at least one set of S4/S3/S16 interfaces enabled.
In this respect, WO 2013/053896 discloses a direct interface “Sx” between an MME or an S4-SGSN and a PCRF, as illustrated in FIG. 3 of the present specification. In accordance with WO 2013/053896, during the attach procedure specified in 3GPP TS 23.401 (v12.4.0), the MME or the S4-SGSN initiates the new interface towards the PCRF and includes at least the UE Identity, PDN Identifier and APN; and the PCRF responds to the MME/S4-SGSN session request, so that the PCRF may subscribe to event notifications from the MME/S4-SGSN at this point. In particular, the Sx interface allows providing access network information to the PCRF, like for example location information, assisting the MME to select the PGW based on policies, informing the PCRF about a User Equipment Aggregate Maximum Bit Rate (UE-AMBR), and steering a UE to certain Radio access type indicating the PCRF to the MME the access type to select by the UE.
WO 2013/053896 of the same applicant discloses examples of interactions between the MME/S4-SGSN and the PCRF carried out during an Initial Attach procedure as specified in TS 23.401.
In an embodiment according to WO 2013/053896 and illustrated in FIG. 1, an attach procedure is carried out during a step S-101, as specified before step 12 in TS 23.401 (v9.8.0) with reference to FIG. 5.3.2.1-1 of TS 23.401. Then, during a step S-102, the MME/S4-SGSN initiates the new Sx interface towards the PCRF and includes at least the UE Identity, PDN Identifier and APN. The UE Identity and PDN Identifier may be used to identify the subscriber and in PCRF selection to locate the PCRF function with the corresponding IP-CAN session established by the PGW. The MME/S4-SGSN may provide additional parameters such as MME/S4-SGSN capabilities and restriction, RAN capabilities and restriction, UE capabilities and restrictions, or any other information that is available in the MME/S4-SGSN and that is relevant for this user and connection.
During a step S-103, the MME/S4-SGSN may send Create Session Request as per normal procedures; during a step S-104, the SGW may send Create Session Request as per normal procedures; and, during a step S-105, the PGW may initiate a new Gx session as per normal procedures.
The PCRF may correlate the Gx session with the Session Request from the MME/S4-SGSN and during a step S-106 the PCRF may respond to the Gx session request as per normal procedures. Then, during a step S-107, the PGW may send a Create Session Response to the SGW as per normal procedures; and during a step S-108, the SGW may send a Create Session Response to the MME/S4-SGSN as per normal procedures.
During a step S-109, the PCRF may respond to the MME/S4-SGSN session request. The PCRF may subscribe to event notifications from the MME/S4-SGSN at this point, e.g. changes to cell-id, S1-connection status or any other information that is available in the MME/S4-SGSN for this user. Eventually, during a step S-110, the attach procedure may continue as specified after step 16 in TS 23.401. Any personalized parameters provided to the MME/S4-SGSN from the PCRF are applied and used internally in the MME/S4-SGSN and in successive procedures of relevance.
At present, different PCRF clients (e.g. BBERF, PCEF, TDF, etc.) can contact the PCRF to request policy control and QoS authorization for service data flows associated with a UE. It may occur that the PCRF of the PCC architecture is contacted by certain PCRF clients even if there is no policy decision applicable by the PCRF for the UE involved. For example, a PCEF deployed in the operator network to make content filtering may unnecessarily contact the PCRF for a UE if the PCRF does not have any content filtering policy for that UE. Of course the PCRF clients cannot know in advance if certain subscriber has certain services, since they do not have any subscriber profile information so, by default, these enforcement points are configured to contact or not the PCRF, but the same criteria are taken for all the subscribers.
According to 3GPP TS 23.203, a PCRF can be contacted by any one of: BBERF by means of Gxx interface, PCEF by means of Gx interface, TDF by means of Sd interface, and AF by means of Rx interface; and, according to WO 2013/053896, the PCRF can also be contacted by MME/S4-SGSN by means of Sx interface. That is, the PCRF has to support at least the PCC interfaces: Gxx, Gx, Sd, Rx, and Sx.
When there is just one PCRF in the PCC architecture, the unnecessary signalling commented above, between PCRF clients and the PCRF, may overload the PCRF, preventing the PCRF from providing the expected policy and QoS control.
On the other hand, when there are more than one PCRF deployed in the operator network, the selection of the right PCRF by the different PCRF clients may require further resources.
3GPP TS 29.213 (v12.3.0) has defined a mechanism to select a same PCRF from different PCC interfaces that are related to the same PDN connection. This mechanism is based on the support of a Diameter Routing Agent (DRA) node in each Diameter realm so that, when the DRA first receives a request for a certain IP-CAN session, the DRA selects a suitable PCRF for the IP-CAN session and stores the PCRF address; subsequently, the DRA can retrieve the selected PCRF address according to the information carried by the incoming requests from other entities. To this end, the DRA has information about the user identity, IP address and the selected PCRF for certain PDN connection. When the IP-CAN session terminates, the DRA removes the information about the IP-CAN session.
That is, when more than one PCRF is deployed in the operator network, a DRA must also be deployed in the network in order to be in charge of selecting a same PCRF for all the nodes that need to interact with it for a same PDN connection, such as e.g. MME/S4-SGSN, BBERF, PCEF, TDF, and AF.
The DRA-based mechanism is based on the assumption that all nodes that interact with the PCRF support Diameter protocol, and that the operator deployment includes a DRA per Diameter realm.
Such a solution may imply a number of drawbacks, amongst others: the operator needs to deploy at least one additional node in the network, namely the DRA; all the PCC signalling (Sx, Gx, Gxx, Rx, . . . ) need to go via the DRA, so that any procedure can suffer delays and the DRA can be a bottleneck when congested; in roaming scenarios, there is also a need to have a DRA in the visited network (Local breakout cases) in order to find the V-PCRF, so that extra delays can be expected. In addition, 3GPP is currently studying the possibility of supporting an XML-based Rx interface on top of HTTP and, in that case, the current DRA solution would not work.